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Executive  Summary 


This  document  describes  the  conversion  of  the  Forces  Mobilization  Model  (FORCEMOB) 
from  the  FORTRAN  programming  language  to  the  C  programming  language.  FORCEMOB  is 
used  in  the  Risk  Assessment  and  Mitigation  Eramework  for  Strategic  Materials  (RAME-SM), 
which  provides  support  to  the  Defense  Eogistics  Agency  (DEA)  in  estimating  potential  shortfalls 
of  strategic  and  critical  materials  (S&CM)  in  a  national  emergency  scenario  and  determining 
materials  (and  quantities  thereof)  to  be  included  in  the  National  Defense  Stockpile  (NDS). 
EORCEMOB  is  stable  and  produces  consistent  results,  but  updating  it  to  a  more  modern 
language  would  be  beneficial  for  software  maintenance  and  development.  Conversion  was 
achieved  through  a  combination  of  automated  translation  with  the  EOR-C  tool  and  human  code 
review  and  modification.  The  C  version  of  EORCEMOB  was  validated  against  the  EORTRAN 
version:  given  identical  data,  it  should  produce  identical  results.  Testing  reveals  that  the  C 
version  of  EORCEMOB  is  identical  to  6  decimal  places,  which  is  well  within  an  acceptable 
range  of  precision.  The  authors  conclude  that  the  C  version  of  EORCEMOB  is  ready  for 
operational  use. 
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1.  Introduction 


This  document  reports  the  conversion  of  the  computer  eode  for  the  Forces  Mobilization 
Model  (FORCEMOB),  a  software  program  used  in  the  Risk  Assessment  and  Mitigation 
Framework  for  Strategic  Materials  (RAMF-SM),  from  the  FORTRAN  77  language  to  the  C 
language.  It  deseribes  FORCEMOB  and  provides  background  context  on  its  use,  explains  the 
impetus  for  code  conversion,  details  the  proeess  by  which  the  code  was  converted,  and 
summarizes  the  result.  Although  the  subjeet  matter  is  inherently  teehnieal,  this  doeument  is 
written  for  a  general  audience. 
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2.  Background 


The  Strategic  and  Critical  Materials  Stock  Piling  Act  calls  for  the  establishment  of  a  National 
Defense  Stockpile  (NDS)  and  requires  biennial  reports  to  the  U.S.  Congress  on  stockpile 
requirements  and  recommendations.  The  Institute  for  Defense  Analyses  (IDA)  assists  the 
Defense  Logistics  Agency  (DLA)  in  determining  these  requirements.  IDA  has  developed  an 
analytical  process,  RAMF-SM,  to  identify  potential  shortfalls  of  strategic  and  critical  materials 
(S&CM)  and  assess  mitigation  strategies.  Identification  of  the  likely  number  and  severity  of 
shortfalls — “Step  2”  of  RAMF-SM — is  accomplished  using  a  suite  of  models  and  data.  This 
document  is  specifically  concerned  with  a  single  model  within  Step  2  of  RAMF-SM;  the  Forces 
Mobilization  Model  (FORCEMOB). 

FORCEMOB  is  used  to  compute  yearly  total  goods  and  services  production  (i.e.,  economic) 
requirements  in  a  national  emergency  scenario.  EORCEMOB  generates  total  goods  and  services 
requirements  based  on  essential  civilian  and  base  military  needs  under  normal  peacetime 
conditions,  plus  economic  demands  stemming  from  the  national  emergency.  EORCEMOB 
modeling  includes  the  exclusion  of  non-essential  civilian  demand,  homeland  event  damage, 
regeneration  of  weapons  lost  and  munitions  expended  in  the  conflict,  and  import  disruptions  or 
export  cutbacks.  EORCEMOB  also  assesses  and  models  options  to  eliminate  production 
shortfalls  (if  extant):  namely,  more  fully  using  existing  industrial  capacity  or  investing  in  new 
production  capacity.  Running  EORCEMOB  generates  U.S.  industrial  production  requirements, 
which  are  then  used  in  later  phases  of  Step  2  to  calculate  S&CM  requirements  and  potential 
shortfalls. 

EORCEMOB  was  created  in  the  early  1990s  and  is  written  in  the  EORTRAN  77  computer 
language.  EORCEMOB  is  approximately  14,000  lines  of  code  (a  flawed  but  frequently  cited 
measure  of  software  complexity).  ^  It  is  a  pure  numerical  computation  program  without  a 
graphical  user  interface  (GUI);  once  run,  EORCEMOB  reads  user-created  input  files,  performs 
mathematical  operations  upon  them,  and  outputs  text  files  containing  results.  Its  operations 
largely  consist  of  matrix  algebra. 


^  Lines  of  code  (LOG)  can  be  a  useful  gross  measurement  of  software  complexity:  for  example,  a  computer 

operating  system  such  as  Microsoft  Windows  is  much  more  complex  than  a  simple  game  such  as  Pacman  and  has 
many  more  LOG.  In  this  vein,  algorithmic  information  theory  describes  objects  in  terms  of  the  computability 
resources  needed  to  specify  the  object  (Kolmogorov  complexity).  However,  LOG  is  affected  by  many  factors  not 
related  to  software  complexity  -  for  example,  the  language  in  which  a  program  is  written  and  stylistic  coding 
practices  -  that  make  it  a  highly  imprecise  measurement.  For  more,  see:  Steve  McGonnell,  Software  Estimation: 
Demystifying  the  Black  Art  (Redmond,  WA:  Microsoft  Press,  2006);  and  Andrei  Kolmogorov,  "On  Tables  of 
Random  Numbers,"  Sankhya  Ser.  A.  25  (1963):  369-375. 
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This  simplified  description  of  FORCEMOB  is  adequate  for  the  purposes  of  this  document, 
but  if  the  reader  seeks  a  deeper  understanding  of  a  particular  point,  IDA  has  produced  extensive 
documentation  of  RAMF-SM  and  its  component  models,  including  FORCEMOB; 

•  IDA  Paper  P-5190  contains  a  complete  overview  of  the  RAME-SM  methodology  used 
for  the  2015  Requirements  Report. 

•  IDA  Document  D-5432  presents  an  overview  of  Step  2  of  RAMF-SM,  including  an 
exhaustive  listing  of  every  model  and  data  item  used  for  analysis  supporting  the  2015 
Requirements  Report. 

•  IDA  Paper  P-2953  is  a  comprehensive  documentation  of  FORCEMOB,  including  full 
mathematical  derivations  of  its  algorithms  and  descriptions  of  individual  EORTRAN 
subroutines. 

•  IDA  Document  D-5433  is  a  new  user’s  guide  to  EORCEMOB  that  includes  an 
unclassified  training  version  of  the  software. 
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3.  Impetus  for  Code  Conversion 


This  document  describes  the  conversion  of  FORCEMOB  from  FORTRAN  77  to  C,  raising 
the  question  of  why  eonversion  is  desirable.  The  answer  is  not  that  FORCEMOB  as  eurrently 
eoded  is  defeetive:  it  is  stable,  bug-free,  and  produees  consistent  results.  The  answer  also  is  not 
that  the  conceptual  methodology  behind  FORCEMOB  is  under  revision:  given  identical  data,  the 
FORTRAN  and  C  versions  of  FORCEMOB  should  and  do  achieve  identieal  results.  Rather,  the 
answer  has  to  do  with  inherent  features  of  the  FORTRAN  77  and  C  languages,  eaeh  of  whieh  has 
advantages  and  disadvantages.  FORTRAN  77  was  a  sensible  ehoice  at  the  time  of 
FORCEMOB ’s  inception,  but  C  is  better  suited  for  new  requirements,  as  this  section  explains. 

FORTRAN  is  one  of  the  oldest  programming  languages,  originally  developed  at  IBM  in  the 
1950s.  There  have  been  many  subsequent  revisions  of  FORTRAN:  FORTRAN  77  (in  which 
FORCEMOB  is  coded),  FORTRAN  90,  FORTRAN  95,  FORTRAN  2003,  and  FORTRAN 
2008.  FORTRAN  is  particularly  well  suited  for  numeric  computation  and  scientific  computing, 
fields  in  which  it  continues  to  enjoy  broad  usage.  FORTRAN  77  has  no  pointers  and  does  not 
allow  aliasing,  meaning  that  the  programmer  can  access  a  speeific  memory  area  only  through  the 
specific  symbol  associated  with  that  memory  area.  These  restrictions  allow  FORTRAN  77 
compilers  to  optimize  code  to  a  greater  degree  than  other  languages  with  more  eomplex  memory 
alloeation,  making  FORTRAN  very  fast.^  FORTRAN’S  relative  simplicity  also  makes  it  very 
stable  and  portable,  meaning  that  programs  written  in  it  tend  to  work  well  on  many  different 
types  of  computers  with  little  maintenance  required.  These  features  all  made  FORTRAN  a  good 
choiee  for  coding  FORCEMOB  at  the  time  of  its  ineeption.  In  particular,  early  1990s  computers 
had  exponentially  less  eomputing  power  than  eontemporary  machines,  and  so  the  speed  of 
FORTRAN  at  number-erunching  was  a  great  advantage. 

However,  disadvantages  have  emerged  over  time.  Although  modem  at  the  time  of 
FORCEMOB’s  inception,  FORTRAN  is  now  an  inereasingly  obsolete  language  that  has  been 
superseded  by  other  languages.  It  is  inereasingly  diffieult  to  find  programmers  experieneed  in 
FORTRAN,  hindering  maintenance  or  modification  of  FORCEMOB.  The  greater  power  of 
modem  computers  can,  in  certain  cases,  negate  the  speed  advantage  of  FORTRAN:  the 
calculations  performed  in  FORCEMOB  now  can  be  done  in  a  few  seeonds  regardless  of 
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Pointers  are  used  in  computer  programming  to  refer  to  a  value  stored  somewhere  in  the  computer  memory  using 
its  address  (i.e.,  they  “poinf’  to  where  the  value  is  stored).  Using  pointers  to  store  two  separate  values  in  the  same 
memory  location  is  called  aliasing.  Programming  languages  without  aliasing  (such  as  FORTRAN)  can  achieve 
faster  performance  than  languages  with  aliasing  (such  as  C)  due  to  ease  of  compiling.  Compiling  code  means 
converting  human-written  code  into  machine-interpretable  binary  code.  This  typically  is  done  automatically  by  a 
specialized  program  called  a  compiler.  In  essence,  programming  languages  without  pointers  are  simpler  and 
hence  allow  the  compiler  to  more  aggressively  fine-tune  the  code  for  speed. 
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language.^  FORTRAN  encourages  reliance  on  global  variables,  which  are  discouraged  in  a  group 
development  setting. 

Another  limitation  of  FORTRAN  relative  to  RAMF-SM’s  needs  is  that  it  is  an  imperative 
language."^  Essentially,  this  means  that  FORTRAN  code  consists  of  a  list  of  step-by-instructions 
for  the  computer  to  execute  in  relatively  linear  fashion.  Although  sufficient  for  some 
applications,  the  imperative  programming  paradigm  has  generally  been  superseded  by  object- 
oriented  programming  (OOP),  in  which  the  programmer  declares  different  types  of  data  objects 
and  interactions  between  them.  OOP  is  particularly  useful  for  combining  multiple  sub-modules 
(possibly  developed  by  different  programmers)  into  a  large  complex  program. 

The  above  point  is  of  critical  importance  for  RAMF-SM.  Currently,  RAMF-SM  uses  many 
different  models  that  must  be  manually  interfaced:  in  other  words,  an  analyst  performs  a  run  of 
one  model,  extracts  results  as  a  text  file  or  spreadsheet,  substitutes  them  into  another  model,  and 
so  on.  This  process  carries  a  high  labor  cost  and  inhibits  reproducibility,  in  that  significant  effort 
is  required  to  track  exactly  what  inputs  were  used  in  a  particular  run  of  a  particular  model 
(keeping  in  mind  that  many  different  runs  are  made  for  a  single  study).  These  issues  could  be 
mitigated  by  integrating  the  models  in  a  single  program  so  that  they  interface  by  explicitly 
defined  computer  code  rather  than  inherently  variable  human  behavior.  Doing  so  could  reduce 
labor  requirements,  allow  greater  traceability  of  results,  and  facilitate  future  development. 
RAMF-SM  models  other  than  FORCEMOB  are  written  in  modern  C  and  C++,  and  so  if  all  the 
models  are  to  be  integrated,  it  makes  more  sense  to  convert  EORCEMOB  from  EORTRAN  than 
it  does  to  convert  the  other  models  to  EORTRAN. 


fortran’s  speed  still  is  useful  for  high-end  and  scientific  computing.  However,  FORCEMOB  is  not 
particularly  computationally  intensive  and  so  does  not  require  a  performance-optimized  language  to  finish  in 
reasonable  time. 

^  Later  versions  of  FORTRAN  do  support  object-oriented  programming,  but  are  not  well-regarded. 
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4.  Conversion  Methodology 


The  company  Cobalt  Blue  offers  a  software  program,  FOR-C,  which  automatically  rewrites 
FORTRAN  77  code  into  C.  This  automated  method  offers  significant  labor  savings  as  compared 
to  the  programmer  time  needed  for  manual  conversion. 

FOR-C  has  a  track  record  of  success  in  converting  large,  complex  analytical  software  from 
FORTRAN  to  C.  Idaho  National  Laboratory  used  FOR-C  to  convert  RELAP5-3D,  a  Department 
of  Energy  and  Nuclear  Regulatory  Commission-funded  model  used  to  simulate  and  analyze 
nuclear  reactors.^  EOR-C  also  was  used  to  convert  Cloudy,  a  model  funded  by  the  National 
Aeronautics  and  Space  Agency  and  National  Science  Eoundation  that  is  widely  used  in  the 
astronomical  community  for  large-scale  plasma  simulation  and  interpretation  of  spectroscopic 
data.^  Notably,  Cloudy  was  about  130,000  lines  of  EORTRAN  77  code — an  order  of  magnitude 
larger  than  EORCEMOB — and  was  successfully  converted  using  EOR-C.  In  sum,  there  is  strong 
evidence  to  suggest  EOR-C  is  adequate  for  conversion  of  EORCEMOB  from  EORTRAN  to  C, 
and  so  we  chose  to  rely  on  it. 

However,  this  conversion  was  not  entirely  automated.  To  ensure  code  quality,  two  human 
reviewers  each  conducted  an  independent,  line-by-line  audit  of  the  C  code  produced  by  EOR-C. 
They  tested  each  subroutine  for  functionality  and  sought  to  ensure  the  code  was  human-readable 
and  followed  programming  best  practices.  These  reviewers  made  a  number  of  manual  changes  to 
the  C  code  produced  by  EOR-C,  as  explained  in  the  following  section. 


^  Mesina,  George.  “Architectural  Advancements  in  RELAP5-3D.”  American  Nuclear  Society  Winter  2005 
Meeting;  Guillen,  Donna,  George  Mesina,  and  Joshua  Hykes.  “Restructuring  RELAP5-3D  for  Next  Generation 
Nuclear  Plant  Analysis.”  American  Nuclear  Society  2006  Annual  Meeting. 

^  Ferland,  G.J.  “Cloudy’s  Journey  from  FORTRAN  to  C,  Why  and  How.”  Astronomical  Data  Analysis  Software 
and  Systems  IX,  ASP  Conference  Proceedings,  Vol.  216,  edited  by  Nadine  Manset,  Christian  Veillet,  and  Dennis 
Crabtree.  Astronomical  Society  of  the  Pacific,  ISBN  1-58381-047-1,  2000,  p.32. 
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5.  Manual  Changes 


While  the  eode  produeed  by  FOR-C  was  funetional,  the  literal  translation  was  diffieult  to 
read.  The  manual  ehanges  deseribed  below  were  applied  to  the  C  version  of  FORCEMOB  after 
running  the  FORTRAN  77  version  of  FORCEMOB  through  EOR-C.  These  changes  greatly 
simplified  the  C  code  for  EORCEMOB  and  did  not  hamper  performance.  Rather,  they  improved 
the  readability  of  code  so  that  EORCEMOB  could  be  more  easily  maintained. 

A.  Simplifying  the  Conversion  with  C  Library  Functions 

The  EOR-C  conversion  of  EORCEMOB  included  literal  translations  of  EORTRAN  77 
library  functions  with  all  of  their  eccentricities  and  overhead.  Eor  the  needs  of  EORCEMOB,  this 
overhead  was  often  unnecessary;  some  C  library  functions  achieve  the  same  goals  with 
insignificant  differences.  When  it  could  be  done  without  sacrificing  functionality,  EOR-C 
converted  functions  were  supplemented  with  close  C  library  equivalents. 

The  main  example  of  this  function  simplification  is  for  copying  the  contents  of  one  string  to 
another.  Eor  this  broad  purpose,  EOR-C  generated  the  functions  f_strncpy(),  fchrncpyQ, 
fchrlcpyO,  which  were  each  used  depending  on  whether  the  lengths  of  strings  were  specified  and 
whether  the  strings  were  null  terminated.  However,  for  the  needs  of  EORCEMOB,  these  details 
do  not  matter.  As  a  result,  the  reviewers  manually  changed  instances  of  these  functions  to  the 
standard,  well-known  function  strcpy_s()  (from  the  C  String  Library),  which  copies  one  string  to 
a  target  string  of  a  specified  length.  The  following  table  shows  a  complete  listing  of  C  Library 
replacements  by  displaying  EORTRAN  77  functions,  what  they  were  converted  to  using  EOR-C, 
and  what  they  were  replaced  with  by  the  reviewers,  as  well  as  justifications  for  the  replacements. 
The  replacements  of  the  EOR-C  generated  the  Sanctions  fjtrncpyQ,  fchrncpy(),  and  fchrlcpyQ, 
are  described  below  as  IDs  six,  seven,  and  eight,  respectively. 
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Table  1.  Summary  of  C  Library  Replacements 


ID 

FORTRAN  77 
Function 

FOR-C  Function 

C  Library 
Function 

Reason  for  Replacement 

1 

CHAR  .EQ. 
CHAR 

f_strcmp(char, 

char) 

strcmp(char, 

char) 

Do  not  need  to  maintain  the  blank 
padding  included  in  f_strcmp()  because 
only  strings  of  the  same  length  are 
compared. 

2 

GETARG(INT 
LINE  INDEX, 
CHAR 
TARGET, 
CHAR) 

getarg(int  line 
index,  char  target 
variable,  char) 

strcpy_s(char 
target,  int 
target  length, 
char) 

Only  one  line  should  be  input  into  the 
command  line  to  run  FORCEMOB.  It  is 
not  necessary  to  specify  which  line  to 
copy  input  from  so  strcpy_s()  will  read 
the  first  line  and  receive  the  correct 
string. 

3 

GETDAT(IYR, 
IMON,  IDAY) 
GETTIM(IHR, 
IMIN,  ISEC, 
IHUND) 

gettim(ihr,  imin, 
isec,  ihund) 

time(NULL) 

The  format  of  the  time  variable  is  not 
important,  so  long  as  the  same 
information  is  included.  Thus  time() 
includes  the  date  and  time  needed. 

4 

INQUIRE(CHAR 
FILE  NAME, 
CHAR  OPTION) 

inqu_opened(int 
unit  number) 

access(char 
file  path,  int 
mode) 

The  option  in  FORTRAN  for 
FORCEMOB  is  always  set  to  "exist". 
This  C  library  equivalent  does  the  same 
check,  simply  checks  if  the  file  exists, 
but  does  not  do  other  unnecessary 
checks  included  in  INQUIRE()  and 
inqu_opened(),  such  as  checking  if  the 
file  is  already  open. 

5 

TARGET  = 
CHAR(1:INT 
TARGET 
LENGTH) 

f_strncpy(char 
target,  char,  int 
target  length) 

strcpy_s(char 
target,  int 
target  length, 
char) 

Do  not  need  to  maintain  blank  padding 
which  is  specified  in  f_strncpy(). 

6 

TARGET  = 
'CHAR' 

fchrncpy(char 
target,  int  length 
to  copy,  char) 

strcpy_s(char 
target,  int 
target  length, 
char) 

Do  not  need  to  maintain  blank  padding 
which  is  specified  in  f_strncpy(). 

7 

TARGET(INT 
TARGET 
LENGTH)  = 
COPIED 

fchrlcpy(char 
target,  int  target 
length,  char 
copied,  int  char 
length) 

strcpy_s(char 
target,  int 
target  length, 
char) 

Do  not  need  to  maintain  fixed  length 
option  which  is  specified  in  fchrlcpy(). 

8 

WRITE(CHAR 
TARGET,  INT 
FORMAT) 

lwrt_seqbeg(char 
target,  int  target 
length,  int  format) 

sprintf_s(char 
target,  int  size, 
format,  ...) 

The  purposes  of  these  two  functions 
are  the  same,  but  the  C  library 
equivalent  uses  C  style  formatting  as 
opposed  to  FORTRAN  style  formatting. 

B.  Creating  New  Functions 

While  the  C  libraries  are  extensive,  in  some  eases  there  was  not  an  equivalent  C  library 
funetion  that  eould  supplant  the  FOR-C  funetion.  In  these  situations,  if  the  FOR-C  function  was 
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more  intricate  than  necessary,  reviewers  wrote  and  substituted  more  simple  functions  specific  to 
the  needs  of  FORCEMOB. 


For  example,  there  are  several  instances  in  which  FORCEMOB  trims  and  concatenates  a 
directory,  a  file  name,  and  an  extension,  and  assigns  this  resulting  string  to  a  new  variable. 
FORTRAN  library  has  a  function  to  achieve  this  goal,  but  the  well-known  C  libraries  do  not.  In 
converting  FORCEMOB,  FOR-C  generated  vcpyncatQ  and  fcpyncatQ  to  achieve  this  purpose. 
However,  both  of  these  functions  had  several  checks  and  features  that  FORCEMOB  did  not 
require,  such  as  the  ability  to  concatenate  an  unspecified  number  of  arrays.  These  features  made 
the  functions  relatively  difficult  to  debug  and  maintain.  In  order  to  reduce  the  number  and 
complexity  of  functions  necessary  to  learn  for  maintenance  of  the  program,  reviewers  developed 
the  function  trimcatQ.  This  25-line  function,  consisting  of  three  simple  loops,  trims  and 
concatenates  three  strings  and  assigns  the  resulting  string  to  a  new  variable,  which  is  all  that  is 
needed  in  FORCEMOB. 

In  addition,  there  are  instances  in  which  FORCEMOB  needs  to  assign  a  specified  number 
of  characters  from  an  array  to  a  temporary  array.  FOR-C  generated  ntSQ  and  nSTRQ  to  handle 
these  situations;  however,  similar  to  the  FOR-C  functions  described  above,  these  functions  are 
difficult  to  read  and  maintain.  Reviewers  replaced  calls  to  these  two  functions  to  calls  of  a 
function  trm().  This  15-line  function  trims  a  character  array  to  a  specified  length  and  assigns  the 
result  to  a  temporary  variable. 

C.  Omitting  FORTRAN  77  Intricacies 

FORTRAN  77  has  several  intricacies  that  FOR-C  preserved  in  the  literal  translation.  If  not 
necessary  to  the  functionality  of  FORCEMOB,  the  translated  intricacies  were  removed. 

For  instance,  by  default  in  FORTRAN  77  all  parameters  are  passed  by  reference.  In  C,  the 
programmer  has  the  option  to  pass  by  reference  or  to  pass  by  value.’  Given  that  all  parameters 
were  passed  by  reference  in  the  FORTRAN  77  version  of  FORCEMOB,  FOR-C  passed  all 
arguments  in  the  C  conversion  by  reference.  In  many  cases  this  is  the  appropriate  choice. 
However,  when  a  scalar  value  is  passed  to  a  function  as  a  limit  or  a  size,  it  is  not  necessary  to 
pass  by  reference.  In  the  FOR-C  literal  translation,  passing  by  reference  in  these  cases  resulted  in 
first  using  a  function  to  pass  the  scalar  to  a  temporary  value,  then  passing  this  address  as  a 
parameter  into  the  desired  function.  This  made  for  a  difficult  and  messy  translation.  To  simplify 


’  Pass  by  value  means  making  a  copy  in  memory  of  the  actual  parameter’s  value  that  is  passed.  Pass  by  reference 
(also  called  pass  by  address)  copies  the  address  of  the  actual  parameter.  Thus,  if  a  parameter  is  passed  into  a 
function  by  value,  the  parameter  will  not  be  modified  outside  of  the  function.  If  it  is  passed  by  reference,  if  the 
parameter  is  modified  in  the  function  it  will  also  be  modified  outside  of  the  function.  The  manner  in  which  a 
coder  decides  to  pass  a  variable  is  primarily  an  issue  of  scope.  In  other  words,  it  depends  on  which  parts  of  the 
program  the  coder  wants  to  see  or  use  the  variable.  Passing  a  variable  by  reference  means  that  the  function  can 
change  that  variable’s  value,  i.e.,  the  scope  of  the  variable  is  larger,  whereas  passing  a  variable  by  value  limits  its 
scope. 
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the  code,  reduce  the  number  of  functions  that  needed  to  be  learned,  and  use  best  C  coding 
practices,  reviewers  made  the  necessary  modifications  to  pass  all  scalar  values  by  value. 

Additionally,  by  default,  FORTRAN  77  passes  a  hidden  length  argument  along  with  all 
string  arguments.  In  the  literal  translation  of  FORCEMOB,  FOR-C  included  this  string  length  as 
a  parameter  for  all  strings  that  were  passed.  Yet  in  most  cases  these  string  lengths  were  not  used 
in  the  function  they  were  passed  to.  In  these  situations,  the  function  parameters  were  reduced  to 
only  those  that  were  used  in  the  functions. 

Furthermore,  FORTRAN  77  strings  are  not  null-terminated,  while  all  strings  generated  by 
C  are  null-terminated  by  default.^  When  converting  FORCEMOB,  EOR-C  generated  the 
function  strini(char,  int)  to  null  terminate  a  string  char  of  length  int.  The  assumed  purpose  of  this 
function  is  to  allow  strings  to  be  passed  between  EORTRAN  77  code  and  C  code  without  errors. 
However,  this  is  not  necessary  for  the  EORCEMOB  conversion  because  all  of  the  code  will  be  in 

C.  All  calls  of  this  function  were  removed,  omitting  234  lines  of  code. 

D.  Clarifying  Variable  Names 

EOR-C  automatically  modified  several  EORCEMOB  variable  names  and  generated  new 
variables  where  necessary.  Eor  clarity  and  consistency,  reviewers  adjusted  these  default  names. 

Eor  example,  EOR-C  identified  non-null  terminated  strings  in  the  EORTRAN  77  version  of 
EORCEMOB  by  appending  an  ‘E’  to  the  end  of  their  variable  name  when  converting  the  code  to 
C.  Again,  since  all  of  the  EORCEMOB  code  will  now  be  in  C,  and  all  strings  in  C  are  null- 
terminated,  it  was  not  necessary  to  distinguish  these  particular  strings.  Therefore  the  appended 
‘E’  was  removed  from  all  variable  names.  This  was  done  to  maintain  consistency  with 
EORTRAN  77  version  of  the  program. 

Additionally,  EOR-C  needed  to  generate  new  variables  when  translating  certain  procedures, 
such  as  the  alternate  returns  procedure.  ^  In  this  case  a  variable  _altretnO  was  generated.  This 
name  gives  no  insight  to  the  reason  for  the  alternate  return.  In  these  cases,  reviewers  modified 
variable  names  so  they  were  more  descriptive.  Eor  example,  most  _altretnO  variables  were 
changed  to  readerr  to  signify  that  the  cause  for  the  alternate  return  was  an  error  in  reading  a  file. 

E.  Removing  Unused  Features  of  Program 

Outdated  function  calls,  particularly  those  to  cancelQ,  were  removed.  This  function  was 
written  to  support  an  older  version  of  EORCEMOB  that  included  a  GUI.  If  the  user  tried  to  exit 
the  EORCEMOB  GUI  in  the  middle  of  a  run,  a  text  file  called  CANCEE.fig  was  created  in  the 


A  null-terminated  string  is  a  character  string  stored  as  an  array  containing  all  the  characters  in  order  and 
terminated  with  a  null  character  ‘\0’. 

^  Alternate  return  arguments  tell  the  program  to  jump  to  a  specified  point  in  a  calling  routine  if  the  subroutine  that 
it  calls  so  directs.  This  is  typically  used  in  the  event  of  some  error  condition. 
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appropriate  directory.  Every  call  to  the  function  cancelQ  searched  for  CANCEL.flg  and  exited 
the  program  if  it  was  found.  Since  the  GEII  has  been  removed,  exiting  the  EORCEMOB  GUI, 
and  therefore  the  function  cancelQ,  has  become  obsolete.  In  the  converted  EORCEMOB, 
cancelQ  and  all  calls  to  it  were  removed. 

F.  Correcting  FOR-C  File  Procedures 

Both  EORTRAN  and  C  contain  several  statuses  with  which  to  open  files.  Eor  example,  files 
can  be  opened  for  reading  only,  for  writing  a  new  fide,  for  replacing  an  old  file.  In  addition, 
EORTRAN  has  an  option  to  open  a  file  with  an  “unknown”  status.  This  status  is  used  in 
EORCEMOB  to  open  a  file  such  as  the  history  file,  which  may  or  may  not  already  exist.  With 
this  option,  EORCEMOB  will  delete  the  old  history  file  if  it  exists,  and  write  a  new  history  file. 
However,  EOR-C  converted  this  “unknown”  status  in  a  slightly  different  manner.  Rather  than 
deleting  an  old  history  file  with  the  same  name,  the  EOR-C  converted  program  would  begin 
overwriting  the  old  history  file.  However,  this  meant  when  an  error  occurred  and  the  program 
terminated  prematurely,  the  error  message  was  printed  but  the  rest  of  the  history  file  from  the 
previous  run  remained  intact.  This  made  it  difficult  to  determine  if  errors  occurred  with  a  quick 
scan  of  the  history  file.  To  amend  this,  rather  than  simply  overwriting  the  history  file,  reviewers 
modified  the  code  so  that  for  each  run  the  old  history  file  is  deleted  and  a  new  history  file  is 
created.  As  a  result,  if  there  is  an  error  in  a  run,  the  error  message  can  be  easily  identified  as  the 
last  line  printed  in  the  history  file. 

G.  Correcting  FOR-C  Directory  Specifications 

The  final  correction  made  to  the  EOR-C  conversion  of  EORCEMOB  rectifies  the  procedure 
that  read  input  and  output  directory  specifications  from  the  Control  Inputs  file.'*^  The  Control 
Inputs  file  specifies  directories  with  the  typical  structure,  where  backslashes  (‘\’)  separate 
folders.  This  presents  a  problem  in  the  conversion  because  in  C  programming  a  single  backslash 
represents  the  escape  character  and  only  a  double  backslash  (‘W’)  can  be  interpreted  as  a  single 
backslash.''  When  the  EOR-C  program  tried  to  read  the  input  and  output  directories  as  it  would 
any  other  line,  the  program  read  single  backslashes  as  escape  characters  and  directories  were 
saved  incorrectly.  A  new  function  was  written,  read_directoryQ,io  read  these  two  directories. 
This  function  reads  a  specified  section  of  a  file  character  by  character  and  replaces  any 
backslashes  with  double  backslashes.  Thus,  directories  are  accurately  read  and  interpreted  from 


The  Control  Inputs  file  is  a  text  file  specific  to  each  run  of  FORCEMOB.  Along  with  input  and  output  directories, 
it  specifies  scenario  dates,  sensitivity  parameters,  options  and  input  files  to  be  used,  and  output  reports  to 
generate. 

' '  Escape  characters  tell  the  compiler  to  escape  the  typical  parsing  context  for  the  following  character.  In  other 
words,  using  a  backslash  means  to  treat  the  character  following  the  backslash  as  special.  For  example,  if  ‘\n’ 
appears  in  a  string,  this  means  to  escape  interpreting  the  ‘n’  as  just  an  ‘n’,  and  instead  treat  the  ‘n’  as  inserting  a 
new  line.  Another  common  use  of  the  backslash  in  C  is  ‘\t’,  which  means  to  insert  a  tab.  Only  if  ‘W’  appears  in  a 
string  is  this  character  combination  interpreted  as  ‘\’. 
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the  Control  Inputs  file.  As  a  result  there  ean  be  eomplete  eompatibility  between  the  input  files 
used  in  the  FORTRAN  and  C  versions  of  FORCEMOB. 
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6.  Testing  and  Validation 


Together,  FOR-C  and  the  reviewers  eonverted  the  old  version  of  FORCEMOB  written  in 
FORTRAN  (let  us  eall  this  F-FM  for  FORTRAN  FORCEMOB)  into  a  new  version  written  in  C 
(whieh  we  will  eall  C-EM).  C-EM  appeared  to  run  well  and  had  no  obvious  errors.  However,  the 
reviewers  also  eondueted  testing  and  validation  in  order  to  ensure  that  C-EM  ean  be  safely  used 
to  supersede  E-EM.  An  automated  script  was  used  to  feed  identical  data  into  E-EM  and  C-EM, 
with  the  expectation  that  they  would  output  identical  results. 

Before  reporting  the  details  of  this  validation,  two  points  must  be  made.  One,  the  purpose  of 
the  validation  was  to  ensure  that  C-EM  produced  identical  results  as  E-EM,  not  to  verify  that 
EORCEMOB  (programmed  in  whatever  language)  is  correct.  This  exercise  is  intended  to 
validate  C-EM  against  E-EM  and  provides  no  insight  into  modeling  accuracy.  Two,  the  reviewers 
only  tested  the  most  commonly  used  configuration  of  EORCEMOB.  EORCEMOB  can  be  run  in 
many  different  ways  depending  on  the  needs  of  the  user  -  for  a  full  listing,  see  IDA  Paper  P- 
2953  -  but  the  overwhelming  majority  of  EORCEMOB  runs  have  been  executed  according  to  a 
single  configuration. 

The  reviewers  conducted  an  automated  validation  procedure.  A  shell  script  runs  E-EM  and 
C-EM  using  identical  data  and  configuration  settings.  The  data  used  for  this  test  run  was 
carefully  chosen  to  engage  all  of  EORCEMOB ’s  major  subroutines  to  test  their  functionality.  In 
particular,  the  combination  of  civilian,  base  military,  and  conflict  military  requirements  is 
sufficiently  large  to  cause  production  shortfalls,  thus  engaging  EORCEMOB’s  emergency 
investment  algorithm.  The  shell  script  loads  their  respective  output  reports  to  the  R  statistical 
computing  platform.  The  shell  script  calls  an  R  script  to  parse  the  respective  output  reports  and 
isolate  the  computed  civilian,  emergency  investment,  military  (base  plus  conflict),  and  total 
requirements  produced  by  E-EM  and  C-EM.  This  means  the  two  versions  of  EORCEMOB  each 
have  four  4x361  matrices  (corresponding  to  production  requirement  forecasts  across  four  years, 
and  360  economic  sectors  plus  1  summed  total).  The  R  script  then  subtracts  the  C-EM  matrices 
from  the  E-EM  matrices,  and  writes  the  calculated  difference  as  four  comma-separated  value 
(CSV)  files.  If  these  files  are  full  of  zeros,  it  indicates  that  C-EM  produces  identical  results  to  E- 
EM.  This  testing  procedure  indicates  that  C-EM  produces  identical  results  (to  6  decimal  places) 
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Specifically,  FORCEMOB  has  many  options  for  how  to  model  military  conflict,  including  modeling  of  pre¬ 
existing  U.S.  weapons  inventories  and  force  structure,  dynamic  allocation  of  assets  between  theaters,  and  more. 
The  most  common  practice  has  been  to  input  a  weapon  requirements  file  containing  the  weapons  systems  and 
quantities  thereof  lost  in  the  modeled  conflicts  (this  is  referred  to  as  Option  OB).  Option  OB  is  the  only 
configuration  the  reviewers  tested. 

1  ^ 

The  design  of  FORCEMOB  means  that  a  single  data  file,  if  carefully  constructed,  is  sufficient  for  testing. 
FORCEMOB  is  a  deterministic  model,  not  stochastic,  and  so  does  not  experience  variation  across  multiple  runs 
(if  input  data  is  held  constant).  Testing  thus  needs  only  to  engage  all  of  FORCEMOB’s  major  sub-routines,  which 
the  test  dataset  did. 
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to  F-FM.  Appendix  A  shows  the  differenee  between  C-FM  and  F-FM  expressed  as  a  pereentage 
of  the  original  F-FM  ealeulation.  The  maximum  error  was  4.01099E-07  percent.  The  minuseule 
diserepaneies  likely  are  explained  by  variation  in  how  C  and  FORTRAN  ealeulate  floating  point 
numbers.  This  is  well  within  an  aeeeptable  degree  of  preeision. 

Reviewers  also  eompared  the  run-time  and  memory  usage  of  F-FM  and  C-FM.  Using  the 
single  eonfiguration  tested,  the  elapsed  time  for  F-FM  is  0.27  seeonds  whereas  the  elapsed  time 
for  C-FM  is  0.212  seeonds.  This  0.058  seeond  differenee  is  negligible.  Reviewers  used  a 
third-party  program  (VMMap)  to  measure  the  memory  used  by  eaeh  version  of  the  program. 
F-FM  uses  24,356  kilobytes  of  random  aeeess  memory  (RAM)  whereas  C-FM  uses  22,740 
kilobytes  of  RAM.  The  below  VMMap  eharts  analyze  memory  usage  in  more  detail.  In  sum,  C- 
FM  is  marginally  faster  and  less  memory-intensive  than  F-FM,  and  well-suited  for  praetical  use 
on  a  eommodity  maehine. 

In  sum,  the  eonversion  produees  identieal  results  with  a  minimal  run-time  and  eomparable 
memory  usage.  We  eonelude  that  C-FM  is  ready  for  operational  use. 


Most  of  the  errors  are  in  the  first  year  because  this  is  when  the  conflict  occurs,  meaning  it  has  the  largest 
shortfalls  and  hence  most  computations  performed  (implying  the  most  floating  point  discrepancies  as  well). 
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Figure  1.  Memory  Analysis  of  F-FM  and  C-FM 
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Appendix  A 

Percentage  Discrepancy  Between  F-FM  and  C-FM 


Table  A-1.  Percentage  Discrepancy 
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Year  1 

Year  2 

Year  3 

Year  4 
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0 

0 
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Appendix  B 

FORCEMOB  Flowchart 


The  compact  disc  (CD)  provided  with  this  document  contains  a  flowchart  depicting  the 
code  structure  of  the  C  version  of  FORCEMOB.  It  is  intended  to  assist  a  programmer  in 
understanding  FORCEMOB ’s  data  structure  and  operations. 
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Comma  separated  values 
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The  FORTRAN  version  of  FORCFMOB 
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Forees  Mobilization  Model 

GUI 

Graphical  user  interfaee 

IDA 

Institute  for  Defense  Analyses 
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Fine(s)  of  eode 
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OOP 

Objeet  oriented  programming 
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Random  aecess  memory 
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Strategic  and  critical  materials 

E-l 


This  page  is  intentionally  blank. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  0704-0188 


The  public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of 
information,  including  suggestions  for  reducing  the  burden,  to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports  (0704-0188), 
1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any 
penalty  for  failing  to  comply  with  a  collection  of  information  if  it  does  not  display  a  currently  valid  OMB  control  number. 

PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 


1.  REPORT  DATE  (DD-MM-YYYY)  2.  REPORT  TYPE 

XX-08-2015  Final 


4.  TITLE  AND  SUBTITLE 

Conversion  of  the  Forces  Mobilization  Model  (FORCEMOB)  from 
FORTRAN  to  C 


3.  DATES  COVERED  (From 


5a.  CONTRACT  NUMBER 


HQ0034-14-D-0001 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


6.  AUTHOR(S) 

Atwell,  Robert 
Romana,  Amrit 
Wallace,  Thomas 


5d.  PROJECT  NUMBER 

DE-6-3247  A12 

5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Institute  for  Defense  Analyses 
4850  Mark  Center  Drive 
Alexandra,  VA  22311-1882 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

IDA  Document  D-5555 
Log;  H  15-000717 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Defense  Logistics  Agency 
Strategic  Materials  Office 
8725  John  J.  Kingman  Rd.  #2545 
Eort  Belvoir,  VA  22060 


10.  SPONSOR/MONITOR'S  ACRONYM(S) 

DLA 


11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 


14.  ABSTRACT 

This  document  describes  the  conversion  of  the  Eorces  Mobilization  Model  (EORCEMOB)  from  the  EORTRAN  programming 
language  to  the  C  programming  language.  EORCEMOB  is  stable  and  produces  consistent  results,  but  updating  it  to  a  more  modern 
language  would  be  beneficial  for  software  maintenance  and  development.  Conversion  was  achieved  through  a  combination  of 
automated  translation  with  the  EOR-C  tool  and  human  code  review  and  modification.  The  C  version  of  EORCEMOB  was  validated 
against  the  EORTRAN  version:  given  identical  data,  it  should  produce  identical  results.  Testing  reveals  that  the  C  version  of 
EORCEMOB  is  identical  to  6  decimal  places,  which  is  well  within  an  acceptable  range  of  precision.  The  authors  conclude  that  the  C 
version  of  EORCEMOB  is  ready  for  operational  use. 
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